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I  INTRODUCTION 


INTRODUCTION 


BACKGROUND 

The  software  product  and  support  market  is  the  most  rapidly  growing  sector 
within  the  very  dynamic  computer  services  market,  as  shown  in  Exhibit  i-i. 

Software  products  were  less  than  10%  of  the  total  computer  services 
market  in  1970. 

By  1986,  software  products  should  make  up  over  28%  of  the  market. 

The  markets  for  both  applications  and  systems  software  will  be  growing 
rapidly,  as  shown  in  Exhibit  1-2.  Systems  software  will  be  growing  the  most 
rapidly. 

Systems  software  includes  not  only  compilers  operating  systems,  but 
such  support  software  as  data  base  management  systems  (DBMS), 
operations  support  products,  report  generators,  and  communications 
monitors  (for  a  full  definition,  see  Section  D  of  this  chapter). 

Some  of  the  individual  industry  sectors  will  be  showing  very  rapid 
growth  as  well,  as  shown  in  Exhibit  1-3. 

A  special  case  is  the  growth  of  software  for  the  very  small  or  personal 
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EXHIBIT  1-1 


U.S.  INFORMATION  SERVICES  MARKET, 

1970-1986* 

($  billions) 


$21 


MARKET 

1970  =  $  3.2  billion 
1980  =  $14.8  billion 
1  986  =  $53.0  billion 


^        Software  Products 

Professional  Services 

I    I    =  Processing  Services 

*  Does  not  include  weapon  system  software 
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APPLICATION  AND  SYSTEMS  SOFTWARE  PRODUCT  GROWTH 


□ 


1981 


=  1986 
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EXHIBIT  1-3 


APPLICATIONS  SOFTWARE  PRODUCTS  MARKETS  - 
GROWTH  IN  SELECTED  INDUSTRY  SECTORS 


INDUSTRY 
SECTOR           '        1  981-1  986 

i  INCREMENTAL  GROWTH 
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computer  market.  Starting  from  an  admittedly  small  base,  this  market 
promises  phenomenal  growth,  as  shown  in  Exhibit  1-4. 

Many  firms  in  the  industry  are  beginning  to  ask  themselves  how  much  mainte- 
nance of  software  packages  is: 

A  separate,  definable  product  area. 

A  growth  area. 

A  profit  center. 

Some  firms  are  already  exploiting  the  potential  of  software  maintenance. 

For  example,  at  a  rapidly  growing  independent  software  company. 
Management  Science  America  (MSA),  software  maintenance  revenue  is 
22%  of  total  revenue  and  still  increasing  as  a  proportion  of  the  total. 

The  leading  firm  in  supplying  packaged  software  to  the 
property/casualty  insurance  industry.  Policy  Management  Systems,  not 
only  sells  its  packages  at  an  average  price  of  over  $250,000,  but  also 
requires  customers  to  sign  a  five-year  maintenance  contract  with  an 
annual  payment  of  25%  of  the  original  cost  of  the  software. 

On  the  other  hand,  customers  are  scrutinizing  many  software  purchases  more 
and  more  closely  to  determine  if  software  really  needs  vendor-supported 
maintenance. 

In  addition  to  these  external  events  and  trends,  many  software  suppliers  are  in 
the  midst  of  evaluating  the  best  way  to  market  and  deliver  software  mainte- 
nance. Some  companies,  for  example,  are  in  the  process  of  integrating  much 
of  their  hardware  and  software  service  organizations. 
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EXHIBIT  1-4 

VERY  SMALL  COMPUTER  APPLICATIONS  PRODUCTS  MARKET 


(System  Cost  <  $1  5, 000) 
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With  this  background  in  mind,  INPUT  deternnined  that  a  report  on  software 
maintenance  would  be  of  high  interest  and  utility  to  field  service  managers. 

METHODOLOGY 

INPUT  interviewed  software  marketing  and  technical  management  from  37 
leading  firms  in  the  industry  to  ascertain  current  industry  practices  and  future 
plans. 

The  questionnaire  used  for  this  purpose  is  shown  in  Appendix  A. 

A  description  of  the  firms  interviewed  is  contained  in  Appendix  B. 

Ten  of  the  firms  are  also  significant  vendors  of  hardware.  In  some  cases, 
their  responses  differed  from  vendors  who  are  software-only  vendors.  To 
highlight  these  differences,  the  responses  from  hardware  and  software-only 
vendors  have  been  segregated  and  contrasted. 

INPUT  also  interviewed  information  systems  (IS)  management  of  leading 
corporations  who  are  members  of  INPUT'S  1982  User  Panel  to  determine  their 
current  and  planned  use  of  vendor-supplied  software  maintenance. 

INPUT  has  also  drawn  on  its  knowledge  from  several  special  consulting  studies 
in  the  areas  of: 

Software  marketing  practices. 

Software  maintenance  business  opportunities. 

New  business  opportunities  in  computer  services. 
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IS  department  organization  and  mission  planning. 


C.  SCOPE  OF  THIS  REPORT 

•  This  report  focuses  on  the  issues  of  the  maintenance  of  packaged  software  in 
the  commercial  environment. 

•  The  following  areas  are  excluded: 

Maintaining  custom-developed  application  software.  This  is  a  different 
kind  of  business  from  maintaining  multiple  copies  of  software. 

Maintaining  other  firms'  software  packages  on  a  third-party  basis.  In 
INPUT'S  view,  this  is  not  a  feasible  business.    (For  further  discussion 
V  -  see  Appendix  C.) 

Maintaining  weapons  systems  software.  Although  large  and  growing, 
this  business  is  highly  specialized. 

D.  SOFTWARE  PRODUCTS  DEFINITIONS 


•  This  category  includes  the  user's  purchase  of  applications  and  systems  pack- 
ages for  use  on  in-house  computer  systems.  Included  are  lease  and  purchase 
expenditures  as  well  as  fees  for  work  performed  by  the  vendor  to  implement 
and  maintain  the  package  at  the  user's  site(s).  Fees  for  work  performed  by 
organizations  other  than  the  package  vendor  are  counted  in  professional 
services.  There  are  several  subcategories  of  software  products: 
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Application  Products  are  software  products  which  perform  processing 
to  serve  user  functions.  They  consist  of: 

Cross-industry  products,  in  multiple-user  industry  sectors. 
Examples  are  payroll,  inventory  control  and  financial  planning. 

Industry-specialized  products,  in  a  specific  industry  sector  such 
as  banking  and  finance,  transportation,  or  discrete  manufactur- 
ing. Examples  are  demand  deposit  accounting  and  airline  sched- 
uling. 

System  Products  are  software  products  which  enable  the 
computer/communications  system  to  perform  basic  functions.  They 
consist  of: 

System  operations  products,  which  function  during  applications 
program  execution  to  manage  the  computer  system  resource. 
Examples  include  operating  systems,  DBMS,  communication 
monitors,  emulators,  and  spoolers. 

System  utilization  products,  used  by  operations  personnel  to 
utilize  the  computer  system  more  effectively.  Examples  include 
performance  measurement,  job  accounting,  computer  operations 
scheduling,  and  utilities. 
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II   MANAGEMENT  SUMMARY 


MANAGEMENT  SUMMARY 


Software  maintenance  will  assume  increasing  importance  over  the  next  five 
years  for  four  reasons. 

The  market  will  be  growing  10  times  in  that  period,  even  faster  than 
the  total  software  market,  as  shown  in  Exhibit  II- 1, 

For  individual  software  products,  especially  those  whose  growth  has 
stabilized,  the  software  proportion  of  total  revenue  can  be  even  more 
attractive,  as  shown  in  Exhibit  11-2. 

Software  maintenance  represents  one  of  the  few  areas  not  subject  to 
cheap  "knock-offs",  as  much  of  the  computing  industry  moves  into  the 
commodity  stage. 

The  cost  pressures  on  supplying  software  maintenance  will  increase, 
since  so  many  present  activities  are  labor-intensive.  Companies  that 
increase  software  maintenance  productivity  will  prosper. 

Software  products  themselves  can  be  highly  leveraged.  Software  maintenance 
and  support  at  this  time  are  not.  Methods  of  improving  leverage  include: 

Innovative  interactive  training  methodologies,  useful  for  both  installa- 
tion training  and  as  a  replacement  for  labor-intensive  and  variable 
quality  hotline  services. 
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EXHIBIT  II-l 


SOFTWARE  AND  SOFTWARE  MAINTENANCE  REVENUE:   1  980-1  986 


=  Upper 

=  Most  Likely 

=  Lower 
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Integrated  software  development  and  maintenance  tools.  These  will 
require  years  of  waiting  before  they  have  an  impact  on  current  mainte- 
nance operations.  However,  companies  that  do  not  make  the  invest- 
ment now  will  fall  behind  in  the  critical  years  ahead. 

Some  of  the  lessons  learned  in  the  hardware  maintenance  business  will  not  be 
applicable  to  software  maintenance.  Integral  parts  of  software  maintenance 
are  making  product  improvements  and  supplying  training  and  consulting  on 
how  to  use  the  product. 

Currently,  the  market  is  fairly  insensitive  to  price;  in  addition,  much  of  the 
market  is  captive,  especially  for  hardware-unique  software.  This  will  change 
in  the  future  due  to  cheap  software  on  one  end  of  the  applications  market  and 
operating  systems  competition  in  all  parts  of  the  market,  including  IBM  main- 
frames. Vendors  can  respond  to  this  in  two  ways: 

Consciously  structuring  value  into  software  maintenance  offerings  by 
providing  more  specificity  in  products. 

Unbundling  software  maintenance  into  its  constituents  and  pricing  each 
appropriately. 

Many  vendors  expect  to  increase  software  maintenance  revenue  significantly 
while  holding  steady  or  decreasing  costs. 

This  will  not  be  feasible  whether  existing  maintenance  processes  are 
followed  (because  of  ongoing  expense)  or  new  technologies  are  imple- 
mented (because  of  startup  costs). 

Vendors  should  review  such  decisions. 
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Many  vendors  are  reviewing  the  organizational  placement  of  software  mainte- 
nance: does  it  belong  in  marketing  (where  it  usually  is)  or  should  it  be  moved 
to  field  service? 

There  are  advantages  and  disadvantages  to  either  location.  The  decid- 
ing points  are  usually  company-unique. 

The  organizational  placement  is  almost  always  less  important  that  the 
strategy  and  plans  for  carrying  it  out. 

One  organizational  move  is  desirable  in  itself:  making  the  central  mainte- 
nance unit  independent  of  the  development  organization.  This  is  not,  how- 
ever, always  feasible. 
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SOFTWARE    MAINTENANCE  PRACTICES 

AND  ISSUES 


Ill       SOFTWARE  MAINTENANCE  PRACTICES  AND  ISSUES 


A,  OVERVIEW 

•  This  chapter  begins  by  defining  the  boundaries  of  software  maintenance  in  the 
vendor  marketplace. 

•  The  remaining  sections  address: 

Pricing. 

Resource  allocation  (budgeting). 
Marketing  and  sales. 
Distribution  methods. 

B.  WHAT  IS  SOFTWARE  MAINTENANCE  ? 

•  "Software  maintenance"  does  not  have  a  commonly  accepted  definition  in 
either  the  user  or  vendor  communities. 
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Information  systems  departments  have  elastic  definitions  of  mainte- 
nance when  maintaining  their  own  in-house  developed  software:  main- 
tenance covers  functions  ranging  from  fixing  minor  bugs  to  system 
rewrites  encompassing  many  man-years  of  effort. 

This  confusion  carries  over  into  vendor  activities.  It  is  at  least  partly 
influenced  by  the  lack  of  clarity  of  IS  departments'  expectations. 

•  Virtually  all  vendors  agree  that  fixing  software  errors  is  included  in  software 
maintenance,  as  shown  in  Exhibit  III- 1.  It  is  interesting  that  a  few  software 
vendors  do  not  see  even  this  as  part  of  their  responsibilities. 

Most  vendors  also  see  improving,  adding,  and  extending  features  as  part 
of  software  maintenance. 

Software  vendors  are  much  less  likely  than  hardware  vendors  to  include 
training  and  consulting  in  maintenance. 

Supplying  conversion  and  interface  assistance  are  seen  by  only  a  minor- 
ity of  vendors  as  being  part  of  maintenance. 

Generally,  software  vendors  include  fewer  activities  in  maintenance 
than  hardware  vendors,  except  for  conversions. 

Hardware  vendors  take  a  more  inclusive  view  of  maintenance 
because  they  are  used  to  taking  a  more  comprehensive  view  of 
customers'  needs;  in  addition  a  bundled  services  attitude  in  many 

cases  has  survived  unbundling. 

i 

The  exception  for  conversions  points  up  the  different  roles  of 
hardware  and  software  companies.  Hardware  companies  will 
only  consider  conversions  within  their  own  hardware  line,  while 
software  companies  will  make  any  conversions  that  are 
economically  attractive. 
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EXHIBIT  III-1 


FUNCTIONS  INCLUDED  IN  VENDOR 
MAINTENANCE  SOFTWARE 


FUNCTIONS 
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SOURCE:  INPUT  Survey 
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•  Hardware  vendors  have  not  changed  their  definition  of  maintenance  in  the 
past  three  years.  However,  30%  of  the  software  vendors  reported  doing  so  to 
adapt  to  new  markets  and  product  areas. 

• '  Both  hardware  vendors  (60%)  and  software  vendors  (44%)  expect  to  be  making 
changes  in  the  activities  included  in  software  maintenance.  Both  types  of 
vendor  will  try  to  reduce  the  extent  of  services  and  activities  included  in 
maintenance,  as  part  of  their  efforts  to  reduce  the  resources  and  costs  of 
software  maintenance. 

•  It  is  noteworthy  that  while  fewer  than  half  the  vendors  view  training  and 
consulting  as  activities  normally  part  of  software  maintenance,  60%  of  ven- 
dors see  dealing  with  user  misuse  or  lack  of  understanding  as  the  key  mainte- 
nance activity,  as  shown  in  Exhibit  1 1 1-2. 

Error  correction  accounts  for  only  13%  of  activities.  (Note:  this  is 
within  the  10-20%  range  commonly  reported  for  in-house  maintenance.) 

Technology  issues  (e.g.,  conversions,  upgrades,  or  improved  efficiency) 
account  for  less  than  one-fifth  of  activities. 

•  There  is  consequently  a  built-in  tension  between  what  vendors  see  as  software 
maintenance  and  the  actual  demands  on  the  software  maintenance  area. 

C.       SOFTWARE  MAINTENANCE  PRICING 

•  Vendors'  current  estimates  for  the  proportion  of  their  software  revenue  which 
comes  from  software  maintenance  ranges  from  4%  to  50%  (vendors  who  still 
bundle  their  software  or  software  maintenance  are  not  included). 
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The  maintenance  portion  of  software  vendors'  revenue  is  15%,  winile 
the  maintenance  portion  of  hardware  vendors'  software  revenue  is  9%, 
as  shown  in  Exhibit  lil-3. 

Software  vendors  see  a  modest  growth  in  this  proportion  over  the  next 
five  years,  while  hardware  vendors  see  the  software  maintenance  share 
increasing  by  a  factor  of  four. 

Some  of  this  increase  is  accounted  for  by  further  unbundling  and 
price  increases  to  captive  customers. 

However,  INPUT  believes  that  some  of  the  expectations  for 
revenue  increases  of  this  magnitude  are  not  realistic,  unless 
sales  of  additional  software  units  would  fall  off  drastically;  this 
is  certainly  not  what  hardware  companies  have  in  mind. 

Consequently,  INPUT  believes  that  hardware  vendors  will  be 
fortunate  if  they  can  match  the  software  vendor's  20%  figure. 

There  is  certainly  room  for  justified  increases  in  software  and  software  main- 
tenance prices.  INPUT'S  ongoing  custom  research  in  this  area  has  shown  that, 
across  industry  and  product  groups,  price  is  not  now  a  major  consideration  for 
most  customers. 

Customers'  high  priorities  are  for  functionality,  flexibility,  and 
support.  Customers  will  buy  a  software  product  that  they  perceive  to 
be  overpriced  (from  a  supplier  cost/profit  standpoint)  if  it  meets  these 
needs  better  than  competing  products. 

Vendors  typically  ascribe  more  importance  to  price  than  customers  do. 

In  general,  vendors  say  that  similar  importance  is  given  to  each  of  the  factors 
in  pricing  software  maintenance  shown  in  Exhibit  II 1-4: 


-  22  - 

©1982  by  INPUT.  Reproduction  Prohibited. 


INP 


EXHIBIT  III-3 


VENDOR  FORECASTS  OF  PROPORTION  OF  SOFTWARE 
REVENUE  COMING  FROM  SOFTWARE  MAINTENANCE 


□ 


*  INPUT  believes  that  20%  is  more  realistic. 


SOURCE:  INPUT  Survey 
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IMPORTANCE  OF  FACTORS  IN  DETERMINING 
SOFTWARE  MAINTENANCE  PRICING 


Value  to 
Customers 


Percent  of 
Software  Price 


Profitability 


Competition 


1  =  Low,  5  =  High 


I    I  =  Software  Vendor      H=  Hardware  Vendor 
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Value  to  customers. 
Percent  of  software  price. 
Profitability. 

Competition  (industry  norm). 

•  However,  84%  of  the  companies  interviewed  only  used  one  method  to  deter- 
mine pricing  for  software  maintenance.  Most  companies  use  a  mechanistic 
approach  to  pricing,  either  a  percent  of  Ihe  package  price  or  a  profitability 
target,  as  shows  in  Exhibit  III-5.  This  means  that  maintenance  pricing  may  be 
too  low  or  too  high. 

Pricing  too  low  leaves  money  on  the  table. 

Pricing  too  high  may  cause  some  customers  to  avoid  vendor  mainte- 
nance, thereby  possibly  reducing  total  software  maintenance  revenue. 
This  may  cause  even  more  serious  longer-run  problems,  as  analyzed  in 
Chapter  V. 

D.       RESOURCE  ALLOCATION 

•  Almost  half  the  vendors  interviewed  (48%)  use  a  formal  budget  process  to 
allocate  resources  for  software  maintenance. 

The  44%  of  software  vendors  which  use  a  budgeting  process  are  gener- 
ally satisfied  with  it. 

While  60%  of  hardware  vendors  use  a  budgeting  process,  they  are  less 
satisfied  than  the  software  vendors.     This  appears  related  to  the 
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METHODS  OF  DETERMINING 
SOFTWARE  MAINTENANCE  PRICING 


SOFTWARE  COMPANIES 


HARDWARE  COMPANIES 

SOURCE:  INPUT  Survey 
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greater  number  of  competing  demands  for  resources  within  a  hardware 
company. 

Different  methods  are  used  to  allocate  resources,  as  shown  in  Exhibit  III-6. 
The  main  methods  are; 

A  percent  or  ratio  applied  to  the  overall  software  budget  or  against  the 
total  number  of  customers. 

A  historical  method,  modifying  the  prior  year's  budget  upward  or 
downward. 

Projecting  future  requirements. 

Some  companies  use  more  than  one  method.  All  methods  are  somewhat 
arbitrary  given  the  difficulty  of  predicting  what  changes  will  be  necessary. 

Some  companies  attempt  to  deal  with  this  by  planning  to  introduce  in 
the  course  of  a  planning  cycle: 

X  new  products. 

Y  major  revisions. 

Z  minor  revisions. 

This  logical  approach  can  usually  yield  at  least  ballpark  cost  esti- 
mates. However,  it  may  result  in  unacceptable  lead  times  and  larger 
or  smaller  changes  than  the  market  needs. 

Resource  allocations  are  not  immutable  (nor  should  they  be).  Three-quarters 
of  respondents  report  shifting  resources  between  the  development  and  main- 
tenance areas. 
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METHODS  OF  ALLOCATING  RESOURCES  TO  SOFTWARE  MAINTENANCE 


NOTE:    Totals  are  more  than  100%  because  some  firms  use  multiple 
approaches. 


I    I  -  Software  Vendors       ^|  =  Hardware  Vendors 
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Maintenance  personnel  represent  an  emergency  source  of  resources  for 
development  (and  vice-versa). 

A  major  product  enhancement  can  be  an  addition  to  an  existing 
product,  or  a  new  product.  (The  strategic  question  of  choosing  the 
correct  alternative  is  discussed  in  Chapter  II,  Section  B-l). 

While  this  flexibility  is  useful  it  can  interfere  with  personnel  and 
product  planning.  Equally  important,  it  can  undermine  the  software 
maintenance  function's  rationale  and  organizational  standing.  (These 
important  organizational  issues  are  dealt  with  in  Chapter  IV,  Section 
A.) 

While  the  percent  of  software  maintenance  revenue  is  expected  to  increase, 
as  shown  in  Exhibit  III-3,  few  companies  expect  to  raise  the  relative  level  of 
resources  devoted  to  software  maintenance,  as  shown  in  Exhibit  II 1-7.  In  fact, 
more  companies  expect  decreases  than  increases. 

Resource  levels  change  for  different  reasons,  not  just  a  single  reason,  such  as 
plans  to  make  software  a  profit  and  loss  (P&L)  center. 

About  30%  of  the  companies  interviewed  now  have  software  mainte- 
nance as  a  separate  P&L,  as  shown  in  Exhibit  III-8.  Another  25%  had 
plans  to  do  so  in  the  future. 

The  feasibility  of  making  software  maintenance  a  P&L  center  will  vary 
from  company  to  company,  depending  on  how  much  control  it  can 
exercise  over  costs,  products,  and  revenue. 
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EXHIBIT  III-8 


SOFTWARE  MAINTENANCE  AS  A  P  &  L  CENTER 


SOFTWARE  VENDORS 


HARDWARE  VENDORS 


SOURCE:  INPUT  Survey 
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E.       MARKETING  AND  SALES 

•  Software  companies  believe  their  customers  are  more  satisfied  than  do  hard- 
ware companies,  as  shown  in  Exhibit 

Software  company  customers  are  rarely  captives,  as  many  customers  of 
hardware  companies  are. 

Software  companies  do  not  have  to  offer  and  support  the  range  of 
software  of  many  hardware  companies. 

Software  companies,  generally  younger  and  smaller,  can  be  more 
responsive  to  customers.  However,  software  companies  often  suffer 
from  growing  pains,  which  can  inhibit  a  satisfactory  customer  service 
effort. 

•  Even  companies  with  satisfied  customers  today  can  have  unsatisfied 
customers  tomorrow  without  adequate  information  on  customer  needs  and 
problems. 

Vendors  generally  use  all  means  of  identifying  software  maintenance 
needs,  as  shown  in  Exhibit  111-10. 

Problem  analysis  reports  and  hotlines  are  most  important. 

Support  staff  feedback,  user  groups,  field  visits,  and  sales  force 
feedback  are  almost  as  important. 

Surveys  are  somewhat  less  important. 

The  differences  between  software  and  hardware  companies  are  mini- 
mal. 
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CUSTOMER  SATISFACTION  WITH  SOFTV\/ARE  MAINTENANCE 


SOFTWARE  COMPANIES 


HARDV;ARE  COMPANIES 

Percent  of  Companies  Perceiving 
Their  Customers  as  Satisfied 


SOURCE:  Input  Survey 
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EXHIBIT  111-10 


IMPORTANCE  OF  METHODS  OF  IDENTIFYING 
SOFTWARE  MAINTENANCE  NEEDS 


METHOD 


TIME 
PERIOD 


IMPORTANCE 


Problem 
Report 
Analysis 


Now 


Future 


4.6 


Hotlines 


Now 


Future 


□ 


4.3 


Support 

Staff 
Feedback 


1  =  Low  Importance,  5  =  High  Importance 

[    I  -  Software  Vendors  =  Hardware  Vendors 


Continued 
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EXHIBIT  111-10  (Cont.) 


IMPORTANCE  OF  METHODS  OF  IDENTIFYING 
SOFTWARE  MAINTENANCE  NEEDS 


METHOD 


User 
Groups 


TIME 
PERIOD 


Now 


Future 


IMPORTANCE 


Field 
Visits 


Now 


3.  2 


3.7 


Future 
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Sales 
Force 
Feedback 


Now 


Future 


3.  4 


Surveys 


Now 


Future 


1  =  Low  Importance,  5  =  High  Importance 

I    I  =  Software  Vendors  =  Hardware  Vendors 
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Respondents  see  the  future  as  much  like  the  past: 


Problem  reports  and  user  groups  will  increase  slightly  in  impor- 
tance for  all  companies. 

Hardware  companies  will  rely  more  on  surveys. 

Other  methods  will  remain  about  the  same. 

•         Most  vendors  now  perceive  software  maintenance  sales  as  almost  automatic, 
needing  little  initiative  on  their  part,  as  shown  in  Exhibit  III- 1  I. 

However,  many  software  vendors,  but  no  hardware  vendors,  believe 
that  more  active  selling  will  be  required  in  the  future,  as  shown  in 
Exhibit  lll-l  I. 

Hardware  vendors  believe  that  their  software  maintenance  markets 
will  continue  to  be  as  protected  as  they  are  now.  This  may  not  be  so; 
the  factors  affecting  this  are  analyzed  in  Chapter  V. 


F.       DISTRIBUTION  METHODS 


•  Distribution  of  software  revisions  is  the  core  and  culmination  of  software 
maintenance  activities.  Every  revision  is  expensive  to  produce  and  creates 
additional  expense  as  users  adjust  to  the  new  software  environment. 

•  It  is  significant  that  software  vendors  appear  to  have  less  expensive,  more 
effective  software  revision  distribution  methods  than  hardware  vendors: 
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EXHIBIT  Ill-n 


SOFTWARE  MAINTENANCE  SALES  EFFORT 
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Only  I  1%  of  software  vendors  average  three  or  nnore  software  product 
revisions  annually,  compared  to  40%  of  hardware  vendors,  as  shown  in 
Exhibit  111-12. 

Virtually  all  software  vendors  interviewed  (84%)  had  90%  or  more  of 
their  revisions  installed  by  their  customers,  as  shown  in  Exhibit  111-13. 

Three-quarters  of  software  vendors  believed  that  all  or  almost  all 
software  problems  were  resolved  in  the  course  of  the  regular  software 
revision  cycle,  compared  to  half  as  many  hardware  vendors,  as  shown  in 
Exhibit  111-14. 

•         This  superior  performance  by  software  vendors  occurs  even  though  they  are 
much  less  automated  in  their  distribution  methods  than  hardware  vendors. 

As  shown  in  Exhibit  111-15,  fewer  than  10%  of  software  vendors  use 
telecommunications  for: 

Identifying  software  problems. 

Solving  software  problems. 

Downloading  software  revisions. 

Hardware  vendors  are  five  times  as  likely  to  do  so. 

About  half  the  software  vendors  have  plans  to  use  telecommunications 
for  these  purposes  eventually,  while  at  least  80%  of  the  hardware 
vendors  plan  to  do  so  eventually. 


-  38- 

©1982  by  INPUT.  Reproduction  Prohibited. 


INPl 
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NUMBER  OF  SOFTWARE  REVISIONS  DISTRIBUTED  ANNUALLY 
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EXHIBIT  111-13 


SOFTWARE  REVISIONS  INSTALLED  BY  CUSTOMER 


PROPORTION  OF 
REVISIONS 
INSTALLED  BY 
CUSTOMER 
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EXHIBIT 


PROBLEMS  RESOLVED  BY  REGULAR  SOFTWARE  REVISION  CYCLE 
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SOURCE:  INPUT  Survey 
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EXHIBIT  111-15 
PERCENT  OF  VENDORS  USING  AND  PLANNING  TO  USE 
TELECOMMUNICATIONS  IN  SOFTWARE  MAINTENANCE 


Identifying 
Software 
Problems : 


SOFTWARE  VENDORS 


HARDWARE  VENDORS 


Solving 
Software 
Problems : 


Downloading 
Software 
Revisions : 


=  Now 


=  Future 


Note:  Percents  refer  to  vendor  "always" 


or  "usually"  using  or  planning  to  use 
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SOFTWARE   MAINTENANCE  ORGANIZATION 

AND  STRATEGY 


IV       SOFTWARE  MAINTENANCE  ORGANIZATION  AND  STRATEGY 


A.       ORGANIZATIONAL  ISSUES 


I .        THE  CUSTOMER  SERVICE  FUNCTION 

•         In  virtually  all  companies  the  software  customer  support  staff  is  ultimately 
attached  to  the  marketing  organization. 

The  typical  hardware  company  organizes  its  software  field  support 
organization  as  shown  in  Exhibit  IV- 1.  A  few  companies,  such  as 
Honeywell,  have  recently  transferred  software  maintenance  responsi- 
bilities to  field  engineering;  i.e.,  the  hardware  maintenance  organiza- 
tion. 

A  number  of  other  hardware  companies  have  been  debating  the  value  of 
a  similar  transfer. 

INPUT'S  observation  is  that  such  transfers  are  neutral.  There 
are  advantages  and  disadvantages  in  having  the  software 
maintenance  in  marketing  (which  in  effect  means  that  it  is 
semi-independent)  as  well  as  having  it  in  field  engineering. 
Exhibit  IV-2  shows  some  of  the  pros  and  cons. 

The  value  of  such  a  transfer  will  depend  largely  on  the  status  of 
a  company's  marketing  and  field  engineering  organizations  at  a 
particular  time,  and  the  attitudes  of  key  personnel. 
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EXHIBIT  IV-1 


SOFTWARE  FIELD  SUPPORT  ORGANIZATION 
IN  A  TYPICAL  HARDWARE  COMPANY 
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EXHIBIT  IV-2 


ORGANIZATIONAL  LOCATION  OF 
SOFTWARE  MAINTENANCE  CUSTOMER  SERVICE  FUNCTIONS 


MARKETING 

FIELD  SERVICE 

Advantages 

Maintenance  is  integrated  with 
pre-  &  post-sales  support 

All  maintenance  activities  are 
CO- located 

Maintenance  activities  can 
directly  support  sales  efforts 

Marketing  can  understand 
customer  product  needs  better 

Staff  can  be  cross-trained 

Hardware  maintenance  staff 
can  be  retrained  for  software 

Disadvantages 

Marketing  is  not  technically 
oriented 

Potential  conflict  between  sales 
support  and  maintenance 

Marketing  management  may 
emphasize  sales  activities 

Hardware  and  software 
technical  issues  is  much 
different 

Inter-departmental  cooperation 
needed  to  sales  support 

Hardware  retraining  is  difficult 
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It  is  important  to  keep  in  mind  that  in  certain  critical  respects  soft- 
ware maintenance  does  not  fit  well  in  either  marketing  or  field 
engineering  (at  least  as  it  is  presently  constituted). 

'    .         Software  in  general  is  unlike  hardware,  as  shown  in  Appendix  D). 

Software  maintenance  will  always  have  ties  to  the  software 
development  function. 

People  In  software  have  different  personal  characteristics  and 
attitudes  from  people  in  marketing  and  field  engineering. 

Regardless  of  the  organizational  sponsorship,  communication  between  the 
customer  and  the  central  maintenance  group  will  follow  the  process  shown  in 
Exhibit  IV-3. 

The  customer  support  representatives  are  not  necessarily  technically 
trained  in  the  internals  of  the  product,  but  have  an  excellent  hands-on 
knowledge  of  the  product  from  the  user's  perspective. 

If  the  vendor  has  a  large  enough  customer  base  and  resources, 
the  representatives  will  specialize  by  product. 

The  staff  can  also  provide  sales  and  installation  support. 

Personality  is  more  important  than  intellectual  skills. 

The  software  support  technicians  are  "middlemen". 

They  back  up  the  customer  supports  reps  on  narrow  or  technical 
issues. 
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They  must  specialize  by  product. 


They  are  filters  to  the  central  maintenance  group. 

The  maintenance  group  is  made  up  of  true  software  technicians  (pro- 
grammers and  analysts). 

They  must  keep  up  some  contact  with  the  field  staff  (and  even 
customers)  so  that  they  do  not  become  divorced  from  the  real 
world. 

They,  in  turn,  must  interact  with  the  new  product  development 
group.  This  relationship  is  the  subject  of  the  next  section. 

THE  RELATION  OF  THE  DEVELOPMENT  AND  MAINTENANCE  FUNCTIONS 

The  role  of  the  software  support  staff  varies  from  company  to  company. 

Generally  speaking,  the  support  staff  is  highly  (usually,  solely)  involved 
with  customer  contact,  as  well  as  error  determination  and  correction. 
There  is  less  involvement  in  the  design  coding  and  documentation  of 
software  revisions,  as  shown  in  Exhibit  IV-4. 

The  software  development  group  mirrors  the  support  group's  involve- 
-    ment,  as  shown  in  Exhibit  IV-5.     Development  groups  in  hardware 
companies  tend  to  be  more  involved  than  those  in  software  companies, 
as  shown  in  Exhibit  IV-6, 

Respondents  express  satisfaction  with  present  arrangements  and  plan 
few  changes. 

There  are  three  basic  models  for  organizing  the  central  software  maintenance 
function: 
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EXHIBIT  IV-4 


SOFTWARE  SUPPORT  STAFF  FUNCTIONAL  INVOLVEMENT 
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SOURCE:  INPUT  Survey 
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EXHIBIT  IV-5 


SOFTWARE  DEVELOPMENT  GROUP  FUNCTIONAL  INVOLVEMENT 


-  Software  Companies  Hardware  Companies 

*  Quality  Control  also  involved  in  17%  of  companies 
**  Documentation  Group  also  involved  in  21%  of  companies  SOURCE:  INPUT  Survey 
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EXHIBIT  IV-6 

EXTENT  OF  INVOLVEMENT  OF 
DEVELOPMENT  GROUP  IN  MAINTENANCE 


SOFTWARE  VENDORS 


HARDWARE  VENDORS 


SOURCE:  INPUT  Survey 
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These  approaches  can  be  labeled  as: 
Coordinated. 
Integrated. 
Independent. 

in  the  coordinated  approach  software  nnaintenance  and  development 
are  separate  entities,  but  they  report  to  the  same  product  software 
manager. 

The  integrated  approach  is  similar,  except  that  the  developer  and 
maintainer  roles  are  not  distinct.  There  is  much  trading  of  responsi- 
bilities. No  one  is  stuck  doing  maintenance. 

The  independent  approach  separates  developers  and  maintainers. 
Separate  maintenance  career  paths  and  specializations  can  be 
developed.  This  is  not  practical  if  the  entire  staff  for  a  software 
product  (or  product  group)  is  small;  i.e.,  under  25. 

Exhibit  IV-7  shows  the  three  approaches  graphically. 

•  Each  organization  option  has  different  effects  on  the  turnover,  morale,  skills, 
and  feasible  project  size  of  the  central  software  maintenance  organization. 
Exhibit  IV-8  summarizes  these  effects. 

The  independent  organization  is  the  most  conducive  to  effective  main- 
tenance activities.  However,  skills  are  needed  to  coordinate  software 
activities  across  a  product.  The  development  group  will  usually  oppose 
this  approach. 


-  52  - 

©1982  by  INPUT.  Reproduction  Prohibited. 


INPl 


EXHIBIT  IV-7 


ORGANIZATIONAL  ALTERNATIVES  FOR 
CENTRAL  SOFTWARE  MAINTENANCE  FUNCTION 
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EXHIBIT  IV-8 


EFFECTS  OF  SOFTWARE  MAINTENANCE  ORGANIZATION  OPTIONS 


MAINTENANCE  PHYSICALLY  AND 
ORGANIZATIONALLY  DISTINCT 

Yes 

No 

(Independent) 

(Coordinated) 

Low  Turnover 

High  Turnover 

ORGANIZATION 
TENANCE  ONLY 

Yes 

High  Morale 

High  Skills  Developed 

Large  Project 
Size  Feasible 

Low  Morale 

Medium  Skills  Developed 

Large  Project 
Size  Feasible 

MAINTENANCE  < 
PERFORMS  MAIN 

No 

N/A 

(Integrated) 

Medium  Turnover 

Medium  Morale 

Medium  Skills 

Medium  Project 
Size  Feasible 
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The  integrated  approach  is  well-suited  to  small  software  groups.  The 
problem  is  that  no  one  wants  to  do  maintenance,  and  the  integrated 
approach  often  degenerates  into  the  coordinated  approach. 

B.       STRATEGIC  ISSUES 

I.        ASSESSING  STRENGTHS  AND  WEAKNESSES 

•  In  developing  a  strategy  for  approaching  software  maintenance,  the  first 
questions  to  ask  are:  "What  kind  of  company  am  I?"  then,  "Will  I  be  the  same 
company  in  five  years?" 

The  obvious  place  to  start  is  with  the  differences  between  hardware 
and  software  companies.  Some  of  the  advantages  and  disadvantages  of 
each  are  summarized  in  Exhibit  IV-9. 

Many  of  the  strengths  and  weaknesses  of  software  companies 
are  due  to  their  relatively  small  size. 

Hardware  companies,  especially  the  mainframe  companies,  are 
more  ponderous  and  structured  organizations.  This  is  not  always 
a  disadvantage  for  a  support  function.  Customers  expect 
support  to  be  uniform  and  by-the-numbers.  There  is  little  room 
for  inspiration  in  a  support  environment. 

Exhibit  IV-9  should  not  be  taken  as  a  prescription  for  every  company. 
Each  company  is  in  a  unique  situation.  Ideally,  each  company  will 
make  its  own  list  of  strengths  and  weaknesses  and  look  for  ways  to 
build  on  its  strengths  and,  at  the  least,  minimize  its  weaknesses. 
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EXHIBIT  IV-9 
SOFTWARE  MAINTENANCE  STRENGTHS: 
HARDWARE  COMPANIES  AND  INDEPENDENT  SOFTWARE  COMPANIES 


INDEPENDENT 

SOrTWAKt  CUlVlrANY 

HAKUWAKb  CUMrANY 

Advantages 

High  profile  in  area  of 
specialization 

Large  resource  base  (dollars, 
people) 

Deep  knowledge  of  products  and 
market  in  area  of  specialization 

Integrated,  comprehensive 
software  products 

Quick  reactions  to  market 

Relatively  easy  for  new  entrants 
to  produce  products 

Attractive  to  entrepeneurial / 
risk-taking  staff  attempting 
breakthrough  products 

Good  geographic  support  for 
marketing  and  support 

Sole  source  for  some  systems 
software 

Much  closer  integration  of 
hardware  and  software 

Disadvantages 

Limited  resource  base  (dollars, 
people) 

Resources  possibly  spread  too 
thin 

Product  line  usually  limited 

Difficult  to  obtain  satisfactory 
marketing  and  support 
geographic  coverage 

Software  products  possibly 
obsolescent,  inadequate,  or 
nonexistent 

Reaction  time  may  be  slow 

Relatively  easy  for  new  entrants 
to  produce  products 

Must  react  to  hardware  changes 

Risk  taking  may  not  be  welcomed 

Software  traditionally  only 
offered  for  own  hardware 
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MAINTAINING  THIRD  PARTY-DEVELOPED  SOFTWARE 


In  the  past,  vendors  tended  to  develop  their  own  software.  There  was  then 
little  question,  or  option,  of  who  would  maintain  the  software. 

This  situation  is  now  changing  as  more  companies  are  adding  specific  software 
products  from  outside  suppliers  to  their  own  line  of  products. 

One  alternative,  followed  by  many  minicomputer  and  small  system 
vendors,  is  not  to  actually  acquire  the  software,  but  to  keep  at  arm's 
length  from  the  vendor. 

At  the  most,  the  hardware  vendor  examines  the  software  and 
recommends  its  use. 

At  the  least,  the  hardware  vendor  merely  maintains  lists  of 
software  products  but  makes  no  recommendations  of  one  over 
another. 

Either  way,  the  hardware  vendor  has  little  control  over  the 
product's  evolution,  its  quality,  or  even  its  existence. 

The  alternative,  followed  by  such  diverse  companies  as  IBM  and  Cul- 
linane,  is  to  buy  up  rights  to  a  product.  Where  product  presence  is 
desirable,  this  gives  a  vendor  a  proprietary  product  and  complete 
control  over  it. 

The  question  then  becomes:  will  the  buying  or  selling  company  maintain  the 
software? 

The  main  reason  for  going  outside  in  the  first  place  is  to  lower  the 
investment  in  time  and  resources  to  develop  a  software  product. 
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Contracting  with  the  seller  to  continue  supplying  central  maintenance 
functions  would  lower  initial  investment. 

It  may  be  possible  as  part  of  the  acquisition  to  take  on  part  of  the 
seller's  technical  and  maintenance  staff.  This  is  a  desirable  alterna- 
tive, if  feasible.  However,  many  people  will  not  want  to  leave  their 
company  or  will  not  last  long  in  a  new,  usually  much  larger  company. 

Exhibit  IV- 10  summarizes  the  pros  and  cons  of  having  the  buyer  or 
seller  maintain  third  party-developed  software. 

NEW  VERSUS  ENHANCED  SOFTWARE  PRODUCTS 

One  of  the  barriers  to  making  software  maintenance  into  a  functioning  P&L 
center  is  that  some  of  the  most  attractive  enhancements  to  existing  software 
can  just  as  easily  be  packaged  as  new  products.  If  this  is  done,  the  benefits  do 
not  accrue  to  the  software  maintenance  organization. 

Many  software  planners  freely  admit  that  their  firms  do  not  have  hard  and 
fast  rules  for  deciding  when  a  bundle  of  capabilities  is  a  new  product  as 
opposed  to  an  enhancement,  or  what  constitutes  a  major  as  opposed  to  a  minor 
enhancement.  Exhibit  IV- 1  I  shows  the  relationship,  and  overlap,  between  new 
product  development  and  maintenance  enhancements. 

Existing  customers,  of  course,  want  all  possible  product  additions  to  be  con- 
sidered enhancements  and  included  as  standard  revisions  covered  by  their 
maintenance  contracts.  Older  customers  (and  some  old-time  vendor  person- 
nel) identify  with  the  bundled  software  era  when  everything  was  "free". 

In  reality,  customers  have  little  or  no  contracted  protection  from 
vendors  announcing  an  "improved"  software  product,  and  charge  cur- 
rent customers  a  significant  proportion  of  list  price,  if  not  the  full  list 
price. 
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EXHIBIT  IV-10 


MAINTAINING  THIRD  PARTY-DEVELOPED  SOFTWARE: 

BUYER  OR  SELLER? 


ADVANTAGES  TO 
BUYER  MAINTAINING 

ADVANTAGES  TO 
SELLER  MAINTAINING 

•  More  direct  quality  control 

•  Easier  maintenance  of  docu- 
mentation and  other  standards 

•  Possible  addition  of  key  seller 
staff 

•  Difficulty  in  motivating  staff 
for  maintenance 

•  Easier  field-central  staff 
coordination 

•  Lower  initial  investment  in  re- 
sources and  management  time 

0  Conserve  scarce  in-house 
staff 

•  Greater  expertise  of  seller's 
staff 

•  Reluctance  of  seller's  staff 
to  join/stay  with  buyer 
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EXHIBIT  IV-11 


DEGREE  OF  INVOLVEMENT  OF  NEW  PRODUCT 
DEVELOPMENT  AND  MAINTENANCE 


Fixing 
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The  only  barrier  to  this  (but  it  is  a  strong  one)  is  the  long-ternn  dannage 
it  will  do  to  the  vendor's  standing  in  the  marketplace.  Some  vendors 
have  damaged  their  reputations  in  this  way,  usually  because  of  serious 
financial  pressures. 

Some  vendors  adopt  a  middle  path,  announcing  a  higher-priced, 
improved  product,  while  including  many  of  the  new  features  as  main- 
tenance revisions  to  current  products. 

This  approach  must  be  thought  out  well  from  a  marketing  standpoint  so 
that  satisfying  current  customers  does  not  undermine  future  sales. 

There  is  a  long-term  technical  burden  in  maintaining  two  or  more 
similar,  but  not  identical,  products. 

For  this  reason  many  vendors  "bite  the  bullet"  and  make  it  financially  advan- 
tageous to  upgrade  to  new  products,  especially  when  the  old  product,  at  a 
technical  dead  end,  will  not  attract  many  new  sales  in  any  event. 

Negative  incentives  can  also  be  applied  by  announcing  that  support  of 
the  old  product  will  be  stopped  soon  (generally  in  less  than  a  year). 

This  will  get  the  new  product  off  to  a  rousing  start  by  giving  it  an 
instant  track  record. 

ASSESSING  SOFTWARE  MAINTENANCE  OPPORTUNITIES 


Not  all  software  packages  are  created  equal,  from  a  software  maintenance 
standpoint. 

Few  customers  will  want  to  go  "bare"  on  operating  system  mainte- 
nance, even  if  they  have  the  chance. 
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On  the  other  hand,  many  purchasers  of  large,  industry-specialized 
packages  buy  the  package  intending  to  modify  it  extensively.  For 
them,  maintenance  is  just  a  tax  on  the  purchase  price. 

A  buyer  of  small,  stable  packages  that  have  been  in  existence  for  some 
time  will  rarely  feel  the  need  for  extensive  maintenance. 

Maintenance  is  perceived  as  highly  valuable  In  large,  complex  packages 
that  the  customer  has  no  intention  of  modifying.  DBMS  is  a  good 
example  of  this  type  of  product. 

These  relationships  can  be  graphically  illustrated,  as  shown  in  Exhibit 
IV-12.  . 

This  is  not  to  say  that  vendors  should  ignore  the  low-need  areas.  These  can  in 
fact  be  the  most  profitable  (at  least  in  the  near  term,  as  shown  in  Chapter 
V).  Two  approaches  can  be  made: 

Tax:  Given  the  relative  price-insensitivity  to  software,  if  a  customer 
sees  a  need  for  a  package  at  $X,  then  the  customer  will  usually  not 
balk  at  an  additional  $.IX  per  year.  If  the  vendor  has  an  attractive 
product,  then  there  should  be  a  mandatory  maintenance  requirement, 
at  least  for  several  years. 

Insurance  Policy;  The  other  approach,  useful  for  small  stable  packages, 
is  to  have  a  nominal  maintenance  price,  covering  error  fixes  only.  At 
the  right  price,  customers  will  buy  the  insurance  for  at  least  several 
years. 

Vendors  should  keep  in  mind  that  historically  maintenance  in  general  has  not 
been  tracked  or  controlled  very  precisely  in  many  data  processing  budgets. 
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EXHIBIT  IV-12 


SOFTWARE  MAINTENANCE  NEEDS 
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In  some  companies,  operations  software  (and  its  maintenance)  is 
included  in  hardware  budgets,  a  remnant  of  bundled  hardware  days. 

In  other  companies,  hardware  and  software  maintenance  budgets  are 
combined. 


In  still  others,  specific  application  software  and  maintenance  expenses 
are  charged  to  a  particular  application  system. 

In  many  companies,  these  different  classifications  are  being  used 
simultaneously. 

There  have  been  some  attempts  to  tighten  up  as  a  result  of  the  current 
recession;  however,  software  maintenance  is  too  scattered  and  mis- 
understood for  cost  cutting  to  have  much  effect. 

THE  IMPORTANCE  OF  SOFTWARE  MAINTENANCE  IN  A  COMPANY'S 
BUSINESS  STRATEGY 

Software  maintenance  can  be  an  important  part  of  a  company's  business 
strategy.  Software  maintenance  is  in  some  ways  the  last  frontier  for  many 
companies. 

Hardware's  price/performance  and  reliability  are  improving  rapidly. 
Unfortunately  for  established  vendors,  these  same  factors  are  turning 
many  hardware  products  into  a  commodity  market. 

Hardware  maintenance  has  been  most  resistant  to  these 
tendencies,  but  even  here  third-party  maintainers  have  gotten  a 
foothold. 

Over  the  longer  term,  rapidly  falling  prices  and  increasing 
reliability   will    reduce   hardware   maintenance  opportunities 
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Software  in  general  is  a  messy  area,  it  is  expensive  to  produce  and 
often  only  meets  customer  needs  marginally.  Software  productivity 
has  lagged  far  behind  hardware  performance.  New  software  products, 
especially  for  smaller  systems,  are  easy  to  produce  in  the  well-known 
garage. 

This  places  pressure  on  established  vendors. 

Outsiders  cannot,  however,  feasibly  offer  add-ons  or  main- 
tenance to  existing  software  products.  Consequently,  it  is  the 
most  protected  area  for  established  vendors. 

Exhibit  IV- 1 3  summarizes  these  relationships  and  trends. 

•  The  conclusion  is  that  software  and  especially  software  maintenance  are 
tough  areas  for  developing  satisfactory  products  economically.  Vendors  who 
can  make  even  marginal  breakthroughs  should  be  able  to  reap  large  rewards. 
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EXHIBIT  IV-13 


STRATEGIC  FACTORS  FOR 
HARDWARE  AND  SOFTWARE  PRODUCTS 


COST  TO 
PROVIDE 

CUSTOMER 
NEEDS 
SATISFACTION 

RELIABILITY 

RESISTANCE 

TO  NEW 
COMPETITORS 

Hardware  Products 

+  + 

+  + 

+ 

Hardware  Enhancements 

+  + 

+  + 

+ 

Hardware  Suppxjrt 

+ 

0 

+ 

+ 

Software  Products 

0 

Software  Enhancements 

0 

+  + 

Software  Support 

+  + 

Key:  +  +  =  Very  Favorable 
+  =  Favorable 
0  -  Neutral 
—  =  Unfavorable 
  Very  Unfavorable 
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V   PLANN  ING  ISSUES 


r 


V        PLANNING  ISSUES 


A.  TRENDS 

•  Trends  already  under  way  could  have  a  significant  impact  on  software 
maintenance  planning.  These  are  coming  from  opposite  ends  of  the  computing 
spectrum;  i.e.: 

The  impact  of  personal  computer  software. 

The  breakup  of  the  IBM  system  software  monopoly  in  the  plug-com- 

r 

patible  market. 
I .        PERSONAL  COMPUTER  SOFTWARE 

•  The  evolving  pricing  structure  of  personal  computer/small  computer  software 
is  far  different  from  that  for  mainframes,  or  even  minicomputers.  To  take 
financial  planning  software  as  an  example: 

Mainframe-based  packages  (e.g.,  EXPRESS,  EMPIRE,  MAPS)  range  in 
price  from  $20,000  to  $200,000. 

Personal  computer-based  packages  (Visi-  and  other  "calcs")  are  two  or 
three  orders  of  magnitude  cheaper.  A  single  VisiCalc  package  can  be 
purchased  for  about  the  cost  of  one  month's  maintenance  for  some  of 
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the  mainframe-based  packages;  it  is  easy  to  see  why  the  product 
manager  for  one  package  sees  VisiCalc  as  his  major  long-term  competi- 
tion. 

•  Given  these  prices,  neither  customers  nor  vendors  of  most  personal  computer 
software  expect  much  in  the  way  of  traditional  maintenance: 

Customer  expect  to  live  with  minor  bugs  and  other  difficulties. 

At  best,  previous  purchasers  can  look  forward  to  a  discount  on  subse- 
quent revisions  to  the  product  (which  may  be  nothing  more  than  the 
current  product  with  bugs  removed). 

Often,  personal  computer  software  is  delivered  without  even  a  tele- 
phone number  or  address  for  followup  contact.  The  dealer  is  expected 
to  provide  installation  and  followup  support;  obviously,  this  support  is 
often  minimal. 

•  Obviously,  a  totally  "let-the-buyer-beware"  environment  cannot  persist. 
However,  personal  computer  application  software  will  habituate  a  new  and 
very  large  generation  of  users  to  a  minimal  level  of  maintenance,  compared  to 
traditional  software. 

•  An  equally  important  change  is  the  lack  of  coupling  among  hardware, 
operating  system,  and  application  software. 

In  a  mainframe-based  system,  application  software  must  typically  be 
tailored  for  a  particular  hardware  environment.  Most  software  is 
aimed  at  a  limited  number  of  environments,  often  just  the  IBM  main- 
frame environment. 

The  original  personal  computer  entrants  (Apple,  Tandy)  preserved  this 
captive  applications  software  approach:  Visicalc,  for  example,  origi- 
nally only  ran  on  Apple.  However,  this  is  beginning  to  fade. 
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The  IBM  personal  computer,  for  example,  was  announced  with 
three  operating  systems  (all  from  independent  suppliers). 

The  contrast  between  these  two  approaches  is  shown  in  Exhibit 
V-l. 

The  falling  price  of  hardware  has  pushed  this  trend  to  its  logical 
extreme,  with  new  models  (e.g.;  Franklin  ACE)  or  add-on  boards  avail- 
able to  mimic  the  operation  of  other  manufacturers'  hardware  envi- 
ronments. 

The  lesson  from  the  personal  computer  marketplace  is  that  soon  little 
software  will  be  automatically  tied  to  a  particular  manufacturer: 
operating  systems  will  be  in  the  same  category  as  application 
programs. 

The  loosening  of  operating  system  monopolies  is  most  evident  in  personal 
computers.  However,  the  popularity  and  spread  of  UNIX,  UNIX-like  systems 
(Xenix,  UNOS,  etc.)  and  the  PICK  operating  system  show  similar  trends  in  the 
minicomputers. 

IBM  MAINFRAME  OPERATING  SYSTEMS 

For  the  first  time  in  the  computer  era  there  are  signs  of  change  in  the  way 
operating  systems  are  supplied. 

Heretofore,  each  mainframe  manufacturer  (IBM  plus  the  "BUNCH") 
supplied  their  own  operating  system(s)  that  were  incompatible  with 
those  of  other  manufacturers. 

The  advent  of  the  plug-compatible  manufacturers  did  not  change  this 
appreciably,  since  IBM-supplied  operating  systems  would  still  run  on  all 
systems. 
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EXHIBIT  V-1 


CONTRASTS  IN  HARDWARE /SOFTWARE  LINKAGES 
(Using  IBM  as  an  Example) 


IBM 

B  Personal 
ComTputer 


CP/M-86 
(Digital  Research) 


Applications 


UCSD  p-System 
(Softech) 


Applications 


MS-DOS 
(Microsoft) 


Applications 
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Competitive  pressures  are  beginning  to  change  this.  IBM  has  already  pulled 
some  functions  back  into  microcode.  More  importantly,  its  competitors  fear 
that  additional,  unannounced  functions  are  already  in  place  in  microcode. 


This  has  led  Amdahl  to  develop,  in  spite  of  some  current  difficulty,  its 
own  implementations  of  microcode/operating  systems. 

The  Japanese  have  for  some  time  been  producing  mainframes  contain- 
ing some  non-IBM  instructions;  their  computers  have  emulated  IBM's. 
Now  there  are  indications  that  the  Japanese  will  also  be  breaking  away 
from  one-for-one  interchangeability  with  IBM  operating  systems. 

•  These  developments  may  lead  to  the  interesting  situation  of  perhaps  half  a 
dozen  IBM-derived  operating  systems,  with  significant  overlap  and  common- 
ality. Presumably,  these  variant  operating  systems  will  be  transparent  to 
most  or  all  current  IBM-oriented  applications  and  operating  support  software. 

This  should  create  significant  competition  in  what  could  be  termed  the 
"plug-modifiable  operating  system"  market. 

Operating  system  users  would  no  longer  be  captives.  Where  warranted, 
users  could  switch  operating  systems  in  the  same  way  that  plug-com- 
patible hardware  is  changed  now. 

Operating  system  maintenance  would  be  forced  to  emerge  from  the 
technical  area  to  the  marketing  front  lines. 

B.       IDENTIFYING  AND  ADDING  VALUE  TO  SOFTWARE  MAINTENANCE 


•         Pricing  will  be  the  key  continuing  issue  in  software  maintenance. 
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Vendor  costs,  perceived  value  to  the  customer,  and  customer  price 
insensitivity  act  togetlner  to  push  prices  up. 

Competition  and  customer  price  sensitivity  act  to  push  prices  down. 

Exhibit  V-2  illustrates  how  these  forces  act  on  both  the  price  floor  and 
price  ceiling. 

The  trends  and  competitive  forces  discussed  in  the  previous  section  of  this 
chapter  will  act  together  to  sensitize  customers  to  software  maintenance 
pricing. 

This  will  place  a  heavier  burden  on  perceived  value  than  previously. 
Customers  will  begin  to  evaluate  exactly  what  they  are  receiving  as  "software 
maintenance". 

One  approach,  which  should  be  useful  to  vendors  and  customers  alike,  is  to 
break  software  maintenance  down  into  its  constituents.  While  the  constitu- 
ents may  vary  from  product  to  product,  the  following  categories  wilt  serve 
most  analyses: 

Error  correction/prevention. 

Improvements  to  featurers. 

Improving  performance/adapting  to  new  operating  environments. 

Training  and  consulting. 

Vendors  could  make  fairly  precise  projections  on  what  customers  would  expect 
to  receive  in  the  last  three  categories.  Software  maintenance  could  then 
truly  be  sold. 
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THE  MOVABLE  PRICING  BOX 

Price 

Competition  Sensitivity 


Costs 
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A  further  step  would  be  to  unbundle  each  constituent  (or  group  of  constitu- 
ents) and  sell  them  separately. 

This  would  be  especially  attractive  for  training  and  consulting. 
Currently,  this  is  the  largest  demand  area  of  the  software  maintenance 
organization.  However,  this  demand  is  denigrated  and  termed 
"customer  misuse".  This  is  because  it  is  usually  "free"  and,  therefore, 
there  are  no  rewards  for  supplying  it. 

To  be  economic,  most  training  and  consulting  cannot  be  supplied  live  on 
a  one-to-one  basis.  New  approaches  will  be  needed. 

Live,  one-to-many  seminars  and  presentations  would  be  more  economic,  but 
unwieldy  and  still  not  cheap. 

Videoconferencing  would  be  more  responsive,  but  it  will  be  years 
before  most  customers  will  have  the  necessary  facilities. 

The  best  bet  is  video-based  training  (now  offered  by  firms  like 
ASI  &  Deltak).  New  developments  in  computer-controlled 
interactive  video-based  training  will  make  these  new  training 
methods  much  more  attractive  and  effective.  They  will  be 
much  more  expensive  to  create,  especially  during  the  take-off 
phase  in  the  technology. 

Training,  probably  in  conjunction  with  an  established  training  firm,  would  be  a 
two-  or  three-stage  process.  Taking  financial  application  systems  as  an 
example: 

The  first  stage  would  review  general  financial  principles  and  systems. 
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The  second  stage  would  focus  on  a  particular  industry  and  its  special 
operational  requirements. 

The  third  stage  would  show  how  the  package  met  these  requirements, 
under  differing  circumstances,  and  how  individual  needs  were  met  by 
particular  features  (and  vice-versa). 

•         These  interactive  materials  could  also  be  used  in  a  slightly  modified  form  to 
supplement  and,  perhaps,  supplant  live  hotline  personnel. 

C.       HARNESSING  TECHNOLOGY 


•  Software  support  and  maintenance  are  second  only  to  marketing  for  being 
labor-intensive.  This  labor  intensiveness  not  only  adds  to  costs  but  also 
threatens  product  quality;  e.g.: 

Relying  on  people  to  provide  hotline  information  and  training  often 
prevents  customer  questions  from  being  answered,  either  correctly  or 
at  all. 

Identifying  and  fixing  software  problems  besides  being  time  consuming, 
is  no  guarantee  that  a  new  error  will  not  be  created.  Software  testing 
is  at  best  only  partially  automated,  and  is  all  too  often  short  circuited 
to  save  time  and  money. 

•  The  next  generation  of  interactive  training  devices  should  go  a  long  way  to 
upgrade  customer  training  and  problem  resolution.  A  better,  standard  product 
would  be  supplied  at  what  would  ultimately  be  a  cheaper  price;  initially,  costs 
would  be  about  the  same. 
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Maintaining  the  actual  software  will  be  a  nnuch  more  difficult  area  for  apply- 
ing technology. 

There  has  been  only  limited  progress  to  date  in  using  technology  effec- 
tively to  develop  new  software  (see  INPUT'S  multiclient  study, 
Improving  the  Productivity  of  Systems  and  Software  Implementation). 
Most  software  development  problems  are  in  the  unautomated  areas  of 
management,  planning,  and  software  design. 

The  productivity  issues  in  software  maintenance  are  at  least  an  order 
of  magnitude  more  difficult.  They  are  not,  however,  unsolvable. 

For  most  vendors,  the  major  productivity  advance  has  been  to  use  some  type 
of  on-line  tool  for  coding  (TSO,  et  al.).  These  speed  up  by  perhaps  50%  an 
activity  that  is  no  more  than  10%  of  the  new  development  process  and  consi- 
derably less  of  the  maintenance  cycle. 

Software  maintainers  would  gain  a  powerful  tool  if  they  had  an  integrated 
development  and  support  environment.  At  present  there  are  few  software 
tools  that  can  usefully  be  applied  to  maintenance.  Software  maintainers  are 
caught  in  a  cleft  stick: 

No  existing  software  development  methodology  provides  an  integrated 
software  development  and  support  environment,  as  shown  in  Exhibit 
V-3.  Proposed  approaches  may  rectify  this,  however  (see,  for  example, 
INPUT'S  September  1982  Report,  Business  Graphics;  Boon  or 
Boondoggle?). 

However,  most  of  the  benefits  will  accrue  to  the  post-implementation 
phase  (i.e.,  after  software  installation).  This  has  greatly  hindered 
acceptance  of  present  tools.  The  weapons  systems  community  has 
come  closest  to  recognizing  these  problems,  and  the  Department  of 
Defense  is  sponsoring  (and  will  soon  require  the  use  of)  the  ADA  Soft- 
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EXHIBIT  V-3 


CONVENTIONAL  SOFTWARE  DEVELOPMENT  PROCESS 
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ware  Support  Environment  package  of  tools.  It  will  be  years,  though, 
before  this  has  an  impact  on  the  maintenance  workload. 

•  Vendors  should  use  such  tools  as  are  available  now  to  the  fullest  extent 
possible.  There  will  be  a  major  long-term  impact  on  the  cost  effectiveness  of 
software  maintenance.  Exhibit  V-4  lists  selected  current  software  produc- 
tivity tools. 
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EXHIBIT  V-4 


SELECTED  SOFTWARE  PRODUCTIVITY  TOOLS 


• 

Constantine/Yourdon /Demarco  Structured  Design 

• 

Jackson's  Program  Design  Methodology 

• 

Warnier-Orr's  Structured  Design 

• 

Cane  &  Sarson's  Structured  Design 

• 

Ross's  SADT 

• 

IBM's  HlPO 
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APPENDIX  B:   VENDORS  INTERVIEWED 


APPENDIX  B:  VENDORS  INTERVIEWED 


•  Ten  hardware  companies,  with  total  revenue  ranging  from  $55  million  to  $4 
billion,  were  interviewed. 

•  Twenty-seven  hardware  companies,  with  total  revenue  ranging  from  $4  million 
to  $125  million  were  also  interviewed. 

•  Multiple  interviews  were  conducted  with  some  companies  to  obtain 
information.  The  typical  respondent  had  the  title  of  Director  or  Vice 
President. 
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APPENDIX   C:   THIRD-PARTY  SOFTWARE  MAINTENANCE 

r 


APPENDIX  C:         THIRD-PARTY  SOFTWARE  MAINTENANCE 


•  Building  up  a  business  in  third-party  software  maintenance  would  be  much 
more  difficult  even  than  third-party  hardware  maintenance,  which  has  market 
entry  problems  of  its  own;  i.e.: 

Finding  skilled  technicians. 

Covering  key  geographic  areas. 

Keeping  up  with  product  changes. 

Overcoming  customer  resistance  to  leaving  the  original  vendor. 

•  In  many  cases,  of  course,  hardware  vendors  will  willingly  devolve  part  of  their 
maintenance  business  for  certain  product  lines  and/or  geographic  areas. 

This  often  makes  sense  since  there  are  relatively  few  economies  of 
scale  in  traditional  on-site  repair. 

Vendors  can  even  face  diseconomies  of  scale  without  a  critical  mass  of 
business. 

•  Software  maintenance  is  quite  different  in  several  key  respects: 

There  are  few  on-site  calls. 
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Fixes  to  known  errors  generally  need  be  made  only  once. 

A  deep  understanding  of  a  software  package  is  usually  required,  an 
understanding  not  easily  gained  by  outsiders. 

Much  maintenance,  actual  and  potential,  is  actually  enhancement.  The 
maintenance  and  development  functions  cannot  be  completely  sepa- 
rated. 

Customer  resistance  to  third-party  software  maintenance  would  be 
even  greater  than  for  third-party  hardware  maintenance. 

•         For  these  reasons,  third-party  software  maintenance  is  generally  not  tech- 
nically feasible  and  will  in  any  case  be  uneconomic  for  buyer  and  seller. 
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APPENDIX  D: 


THE  SOFTWARE  MAINTENANCE  ENVIRONMENT 


A.       GENERAL  SOFTWARE  ISSUES 

•  It  is  important  to  understand  how  software  maintenance  relates  to  software  in 
general. 

•  The  software  development  process  consists  of  the  following  steps. 

Analysis. 

r 

Design. 
Coding. 
Testing. 

•  This  is  shown  in  more  detail  in  Exhibit  D-l. 

The    conceptual    content    is    identical    whether    new  development, 
enhancements,  or  error  corrections  are  involved. 

This  general  process  is  equally  applicable  to  vendors  and  IS  depart- 
ments. 


-  105  - 


©1982  by  INPUT.  Reproduction  Prohibited. 


INPUT 


EXHIBIT  D-1 


THE  SOFTWARE  PROCESS 
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REQUIREMENTS 
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From  a  life  cycle  planning  and  cost  standpoint,  there  are  two  phases: 
Development  (containing  30%  to  40%  of  costs). 

Maintenance  (including  error  correction  and  some  enhancements,  and 
containing  up  to  60%  to  70%  of  costs). 

These  percents  are  based  on  reasonably  reliable  data.  Unfortunately,  much 
software  cost  data  is  very  soft.  Historic  data,  nonstandardized  and  not  con- 
sistently gathered,  often  lacks  linkages  between  project  event  reporting  and 
cost  reporting.  (This  is  discussed  in  more  detail  in  the  next  section  of  this 
chapter.) 

Cost  estimating  tools  are  in  their  infancy. 

Recent  studies  for  the  Air  Force  have  shown  that  cost  estimates  for 
the  average  software  projects  undertaken  for  them  were  60%  of  the 
actual  figure. 

The  variances  were  nonlinear;  i.e.,  correction  factors  would  not 
help. 

Different  software  environments  and  applications  make  the 
same  model  behave  differently,  sometimes  erratically. 

These  kinds  of  problems  are  not  because  of  a  lack  of  estimating 
models.  Some  of  the  most  discussed  models  are  shown  in  Exhibit  D-2. 

Most  models  now  focus  on  the  early  (development)  part  of  the 
life  cycle. 
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EXHIBIT  D-2 
SELECTED  SOFTWARE  ESTIMATING 


SOURCES 


•  PRICE  Software  Lifecycle  Model  (RCA  PRICE  Systems) 

•  Quantitative  Software  Management,  Inc.  (L.  Putnam) 

•  Department  of  Defense  Micro  Estimating  Procedure 

•  SOFCOST,  Grumman  Aerospace 

•  Doty  Associates 

•  Tecolote  Research,  Inc. 

•  Boeing  Computer  Services  Model 

•  TRW  Model  (Wolverton) 

•  Aerospace  Corporation  Model 

•  USAF,  Electronic  Systems  Command 
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Maintenance  resource  estimating  is  subject  to  enormous  varia- 
tion. 

•  There  are  various  tradeoffs  between  developing  new  software  and  enhancing 
existing  software.  One  view  is  presented  in  Exhibit  D-3. 

These  curves  should  only  be  taken  as  suggestive,  given  the  lack  of 
reliable  software  costing  data. 

It  is  obviously  in  the  interests  of  those  who  would  maintain  software 
(and  make  a  business  of  doing  so)  to  devise  methodologies  to  keep  the 
maintenance  cost  curve  from  rising. 

B.  VENDOR-SPECIFIC  ISSUES 

•  Vendors  have  additional  software  issues  to  be  concerned  with: 

Software  products  as  part  of  an  overall  marketing  strategy. 

Whether  to  bring  out  a  new  feature  as  an  enhancement  to  an  existing 
product  or  as  a  new  product. 

C.  RELATION  OF  HARDWARE  AND  SOFTWARE 

•  There  has  been  a  trend  for  software  costs  to  increase  relative  to  hardware 
costs.  Exhibit  D-k  shows  the  general  relationship  over  time.  Different 
installations  can  be  at  different  points  on  the  curve  at  any  time,  depending  on 
their  needs,  applications,  and  sources  of  software. 
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EXHIBIT  D-3 
DEVELOPMENT  -  MAINTENANCE  TRADEOFFS 


23456789  10 
Years  Between  Redevelopment 

^—  Maintenance  costs  plus  development  costs 

Maintenance  costs 

'■       ,  ■  Development  costs 
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GENERAL  HARDWARE /SOFTWARE  COST  TRENDS 


100%  ■  ™»  ^ 


1982 


(Adapted  from  Barry  Boehm) 
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Hardware  costs  often  fall  in  absolute  terms,  and  almost  always  in 
relation  to  processing  accomplished. 

There  have  been  very  few  analogous  advances  in  software  productivity. 

It  is  useful  to  contrast  the  hardware  and  software  life  cycles  as  is  done  in 
Exhibit  D-5.  Many  parts  of  the  two  processes  are  similar. 

As  a  result,  those  with  a  hardware  background  sometimes  under- 
estimate the  magnitude  and  importance  of  the  real  differences 
between  the  hardware  and  software  cycles. 

V  In    software,    the    design/development    phase    is  critically 

important;  there  is  nothing  analogous  to  the  manufacturing 
phase. 

The  maintenance  phase  is  much  more  important  in  software,  not 
only  because  more  initial  bugs  may  appear,  but  also  because 
software  is  far  more  enhanceable  than  hardware. 

Software  may  become  nonfunctional,  but  it  doesn't  wear  out.  in 
principle,  software  is  eternal;  in  practice,  it  is  still  usually  so 
machine-  and  application-dependent  that  it  pays  to  discard 
rather  than  rework  it.  (This  may  change  in  the  future.) 

Hardware  design  and  manufacturing  is  logical  and  scientific.  Software  design 
and  building  is  still  much  more  of  an  art  than  a  science.  Scientific  design 
principles  are  in  their  infancy.  Software  construction  is  a  handicraft,  the 
increasingly  used  term,  software  engineer,  is  a  misnomer. 

These  observations  apply  to  almost  all  new  software  development. 

Software  maintenance  is  far,  far  behind  new  development. 
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EXHIBIT  D-5 


HARDWARE /SOFTWARE  LIFE  CYCLE  COMPARISONS 


HARDWARE 

SOFTWARE 

Development 

Determine  User  Requirements 

Determine  User  Requirements 

Develop  Product  Concept 
(Functional  Design) 

Develop  Product  Concept 
(Functional  Design) 

Soecifv  Comoonent  Desicin 
(Detailed  Design) 

Soecifv  Comnonpnt  Dp<5ian 
(Detailed  Design) 

Build  and  Test  Prototype 

Implement  and  Test  Programs* 

Develop  Manufacturing 
Techniques 

Manufacturing/ 
Installation 

Manufacture  Product 

Make  Product  Available 
to  and  Train  User 

Copy  Programs* 

Make  Program  Available  to  and 
Train  User 

Maintenance/ 
Improvement 

Maintenance  (Correct  Com- 
ponent Failures) 

Maintenance  (Correct  Implemen- 
tation and  Design  Errors)* 

Recall  Product  to  Correct 
Design  Flaws 

Enhance  Product 

Maintenance  (Provide  Enhanced 
Capabilities:    Adapted  to 
Changed  User  Environment) 

Phase-Out 

Unit  is  Unusable  and  Unrepair- 
able (Replace  with  New  Unit) 

Software  May  Migrate  to 
New  Hardware  Generation* 

Product  is  Obsolete 

Product  is  Obsolete 

*  MARKS  IMPORTANT  DIFFERENCES 
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D.       THE  SOFTWARE  MAINTENANCE  ENVIRONMENT 


•  The  general  software  maintenance  process  is  similar  in  principle  to  the  soft- 
ware development  process  in  terms  of  the  sequence  of  the  tasks  and  the 
general  skills  required. 

•  However,  there  are  significant  differences  between  software  development  and 
.-  maintenance.    There  is  a  common  misconception  that  software  maintenance 

demands  fewer  skills  than  does  software  development. 

•  This  is  not  true;  if  anything,  software  maintenance  may  be  more  demanding  in 
general  than  development;  e.g.: 

Support  is  often  necessary  for  multiple  versions  of  software  (e.g., 
where  packages  have  been  semi-customized). 

Unforeseen  requirements  must  be  coped  with. 

-  There  are  often  severe  capacity  and  performance  constraints. 

-  The  most  important  software  maintenance  will  be  carried  out  in  a 
crisis  environment. 

•  While  the  requirements  are  often  more  demanding  than  in  the  development 
area,  the  resources  to  carry  them  out  are  often  inferior. 

Software  maintainers  must  work  in  an  obsolescent  environment. 

Documentation  is  often  poor,  sometimes  nonexistent. 
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Documentation  is  often  poor,  sonnetinnes  nonexistent. 

Productivity  tools  are  even  less  advanced  than  in  the  development 
area. 

•  It  is  not  surprising  that  maintenance  can  be  very  expensive.  According  to  one 
study,  while  the  cost  per  line  of  new  code  averaged  $75,  maintenance  could 
cost  as  much  as  $4,000  per  line  of  code. 

This  is  because  the  later  in  the  life  cycle  that  a  program  is  changed, 
the  more  expensive  the  change  becomes,  as  shown  in  Exhibit  D-6. 

Not  only  do  previous  steps  have  to  be  retraced,  but  sometimes  the 
design  of  the  system  itself  will  no  longer  be  appropriate  for  the  newly 
required  function. 

E.       KNOWLEDGE  REQUIRED  FOR  SOFTWARE  MAINTENANCE 

r 

•  Three  different  levels  of  knowledge  are  required  to  perform  satisfactory 
software  maintenance: 

Technical  knowledge. 

Functional  knowledge. 

Application  knowledge  (for  application  software). 

•  Currently,  there  is  considerable  confusion  among  these  three  levels.  There  is 
a  tendency  to  focus  on  technical  knowledge  and  issues,  in  large  part  because 
of  the  obvious,  critical  problems  to  be  resolved. 
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However,  there  is  also  an  element  of  comfort  involved  in  dealing  with 
familiar  technical  issues. 

Exhibit  D-7  shows  what  is,  in  INPUT'S  view,  the  proper  relationship 

among  the  three  levels  of  knowledge. 

Technical  knowledge  focuses  on  software  methodology;  i.e.: 
Software  system  design/modification. 
Software  module  design/modification. 
Coding  and  languages. 

Software  problem  identification/resolution. 

Pre-operation  =  debugging,  testing,  and  verification. 

Post-operation  =  maintenance. 

This  knowledge  resides  in  computer  programmers  and  technical 
assistants.  The  skill  levels  required  may  range  from  low  to  high. 

Functional  knowledge  is  nonapplication  related,  but  includes  both  software 
and,  increasingly,  hardware  issues. 

Examples  include: 

Data  base  management. 

Networks. 

Distributed  data  processing. 
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KNOWLEDGE  LEVELS 
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This  knowledge  resides  in  computer  scientists.  Required  skills  range 
from  medium  to  very  high. 

Application  knowledge  builds  on  technical  and  functional  knowledge,  it  is 
critical  to  understand  the  ultimate  purpose  of  an  applications  package  to  use 
the  package  effectively. 

Examples  include: 

Banking  systems. 

Insurance  systems. 

Manufacturing  systems. 

Financial  systems. 

This  knowledge  resides  in  applications  specialists  who  should,  however, 
have  enough  technical  knowledge  to  communicate  and  understand  the 
technical  specialists. 

CURRENT  SOFTWARE  MAINTENANCE  PROBLEMS 

The  division  of  responsibility  is  now  often  unclear  among  the  field,  marketing, 
development,  and  maintenance  organizations  for  identifying  and  making 
changes  to  software. 

The  process  is  very  labor-intensive. 

Methodological  approaches  are  uncertain. 
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Scarce  and  expensive  skills  are  often  diverted  to  coding  and  clerical 
functions. 

•  Relatively  few  tools  exist.   What  does  exist  is  of  variable  quality/utility.  In 
any  case,  tools  are  not  standardized. 

•  The  result  is  a  high-cost,  sometimes  unsatisfactory  product. 
G.       THE  SOFTWARE  MAINTENANCE  IMAGE 

•  It  is  almost  impossible  to  overstate  the  horrible  image  attached  to  software 
maintenance. 

"Garbage  picker"  might  be  appropriate. 

There  is  a  strong  view,  held  by  both  developers  and  maintainers,  that 
no  advancement  is  possible,  and  that  only  inferior  people  get  involved 
'     with  maintenance.    A  software  maintainer  does  simple-minded  work 
and  does  not  improve  professionally. 

•  The  reality  usually  is  bad. 

-         Maintenance  personnel  often  work  with  obsolescent  software. 

The  reward  for  success  is  being  stuck  in  a  particular  application  indefi- 
nitely. 

There  is  no  obvious  career  path  (except  out  of  maintenance). 
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There  is  no  body  of  knowledge  or  tools  to  make  the  work  easier  or  more 
professionally  fulfilling. 

While  the  objective  requirements  of  software  maintenance  are  at  least  as 
demanding  as  in  development,  this  is  not  always  perceived  by  those  assigning 
or  performing  the  work.  The  result  is  unsatisfactory  performance  in  terms  of 
one  or  more  of  the  following: 

Quality  of  deliverables. 

Cost. 

Time  required. 

Some  organizations  are  more  successful  than  others  in  improving  both  the 
image  and  product  of  software  maintenance  (the  two  are  closely  related): 

Some  will  call  it  something  else  or  avoid  calling  it  anything  ("X" 
System  Group,  rather  than  "X"  System  Maintenance  Group).  This  can 
be  surprisingly  effective,  but  is  often  difficult  to  do  in  large  organiza- 
tions which  prefer  clarity  to  obscurity  In  titles. 

Others  purposely  mix  development  and  maintenance  within  the  same 
group.  This  works  even  where  maintenance  is  a  very  high  proportion  of 
work  done. 

The  most  interesting  case  is  the  systems  programming  staff  in 
customer  organizations,  which  in  reality  performs  almost  pure  main- 
tenance. Yet  this  function  is  very  high  status,  for  a  mixture  of 
reasons: 
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Systems  programmers  deal  with  the  heart  of  the  computing 
system.  The  mystique  rubs  off. 

In  the  past,  the  job  was,  in  fact,  much  more  creative  than  it  now 
is.  It  used  to  be  common  to  make  operating  system  changes  for 
a  particular  installation. 

.         Systems  programmers  are  viewed  as  a  repository  of  technical 
knowledge  (and  often  are).  This  confers  status. 

The  case  of  the  systems  programmers  is  not  directly  applicable 
to  other  software  maintenance.  However,  there  are  lessons  that 
should  be  applied. 

In  general,  though,  the  exceptions  merely  prove  the  rule  that  software  main- 
tenance is  looked  down  on  and  is  often  ineffective. 

There  is  high  turnover. 

^         Much  of  the  work  is  costly  and  ineffective. 

There  is  little  sense  of  direction  or  view  of  software  maintenance  as  an 
organized  discipline. 
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APPENDIX  E: 


HYPOTHETICAL  SOFTWARE  PRODUCT: 
TEN-YEAR  HISTORY 


ASSUMPTIONS 


•  Peak  sales  in  year  six. 

•  Introductory  price  intentionally  low;  raised  to  market  price  in  year  three;  10% 
annual  increase  until  year  nine. 

•  No  charge  for  maintenance  first  year  after  sale;  thereafter,  assumed  that  all 
customers  are  under  maintenance. 

•  Annual  maintenance  cost  is  12%  of  the  sales  price  in  the  same  years. 


-  123  - 

©1982  by  INPUT.  Reproduction  Prohibited. 


INPUT 


01 

o 

LL 

LU 
D 
Z 
LU 

> 
LU 

LU 

u 
z 
< 
z 

LU 
H 
Z 

-  < 

lIj  ^ 


H 

QQ 

X 

X 

LU 


< 

u 

< 
a. 


I- 

u 

D 
Q 
O 
Qi 
O. 

_l 
< 

u 


Q 
Z 
< 
H 

LU  LU 


H 

o 

Q. 

> 


UJ  < 
01 

< 
I- 
o 

if) 

01 

< 

UJ 

>- 


LU 

1- 


z  o 

^  21  < 

LLl  UJ  h- 

I-  G  O 

Z  H 


UJ 

_1  D 
<  Z 

I-  LU 

o  > 

H  LU 


1/1 

■o 

c 

t/i 
3 
O 


LU 
U 

Z  LU 

<  13 

z  z 

UJ  LU 

I-  > 

Z  LU 

-  (ii 


1/1 
T3 
C 
rs 
</) 
3 
O 


LU 

u 

Z  h- 

^  z 

LU 
I- 

Z  LU 
<  ^ 


■a 
c 

1/1 

3 
O 

•(-> 


u 
z 

O  UJ 
Z  l- 
3  Z 


UJ  LU 

<  ^ 

UJ 

u  > 


< 


LU 


c/i 

■a 
c 

rS 
(/I 
3 
O 
JZ 
■>-> 


LU  1-  re 


z  o 


< 

LU 


(X5 


o 


CN 


(.D 

no 


o 


o 

tD 

CN 

00 

CO 

CN 

CO 

CO 

o 

in 

00 

CO 

CN 

(Ti 

cr> 

CN 

LD 

o 

s 

s 

CO 

C» 

CO 

o 

o 

03 

IS) 

CN 

00 

00 

CN 

00 

00 

00 

oo 

in 

00 

IS> 

CO 

CO 

in 

o 

CN 

ro 

00 

-co- 


CN 
CN 


CN 


IS) 
CN 


CN 


OO 


00 


00 


U3 

00 


o 

CN 


O 

CO 


O 

00 


o 

00 
00 


o 

00 

in 


o 

CO 


o 

00 

en 


o 

00 


o 

00 
00 


o 

O 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

CN 

cn 

oo 

o 

=r 

o 

in 

tS3 

o 

o 

00 

=f 

<x» 

(X) 

in 

to 

</}- 


o 


in 


CO  o 
t—  CN 


CN 

rsi 


CN 


CN 


CO 
CN 


o 

ro 


o 

00 


o 

CN 


o 

(XI 


o 
o 


00 


o 

in 


o 
o 

CN 


in 


o 

in 

(N 


to 


o 

in 


o 
o 

CN 


00 


o 
o 

CN 


O 
O 

CN 


-  124  - 

©1982  by  INPUT.  Reproduction  Prohibited. 


INDEX 


INDEX 


Page 


Budget  process  25 

Central  software  maintenance  function 

models  for  organizing  48,52 

organizational  alternatives  53 

Cost  estimating  107-108 

Customer 

needs,  information  on  32 

satisfaction  32-33 

service  function  43,46,48 

Degree  of  involvement  of  new  product  development  and  maintenance.  60 

Development  and  maintenance 

relation  of  functions  48,1  14 

shifting  of  resources  between  27 

Development  group,  involvement  in  maintenance  50-51 

Distribution  methods  36,38 

Effects  of  software  maintenance  organization  options  54 

Frequency  of  maintenance  activities  21 

Hardware  and  software 

life  cycle  comparisons  107,113 

relation  of  109,112 

Hardware  maintenance  lessons,  applicability  of  14 

IBM  mainframe  operating  systems  69,71 

Interactive  training  75 

Leverage,  methods  of  improving  I  I 

Management  summary  11-15 

Marketing  and  sales  32,36 

Marketing  approaches,  new  32,74 

Methodology  7 

New  versus  enhanced  software  products  58 

Organizational  issues  43 
Organizational  location  of  software  maintenance  customer 

service  functions  45 


©1982  by  INPUT.  Reproduction  Prohibited 


-  125  - 

INPUT 


Page 


Personal  computer 

market  1,5 

software  67-69 

Price  sensitivity  22 

Pricing  71,73 

Problems  resolved  by  software  revision  cycle  41 

Productivity  76 

Report  exclusions  8 

Report  methodology  7 

Revenue,  software  and  software  maintenance  11-13 

Software  development 

difference  from  maintenance                               "  48 

group  functional  involvement  50 

maintenance  tradeoffs  I  10 

Software  field  support  organization  44 

Software  issues  105 
Software  maintenance 

adding  value  to  71-72,74-75 

as  a  P&L  center  3 1 

business  strategy  64-65 

changes  in  level  of  resources  committed  to  30 

communications  46-47 

definition  17-18 

environment  105 

image  120-122 

in  EDP  budgets  62,64 

increased  importance  of  I  I 
knowledge  required  for                                                               I  15,1  17-1  19 

methods  of  allocating  resources  to  28 

methods  of  identifying  needs  34-35 

needs  63 

opportunities,  assessing  61-62,64 

organizational  placement  of  15 

problems  119-120 

sales  effort  37 

strengths:  hardware  companies  and  independent  software  companies  56 

Software  modification  costs  116 

Software  process  106 

Software  product  and  support  market  I 

Software  productivity  tools  78-79 

Software  products  definitions  8-9 
Software  revisions 

distributed  annually  39 

installed  by  customer  40 


-  126  - 

©1982  by  INPUT.  Reproduction  Prohibited. 


INPU' 


Page 


Software  support  staff  functional  involvement  49 

Strategic  issues  55,66 

Technology  15-16 

Telecommunications  in  software  maintenance  42 
Third  party-developed  software,  maintaining  57-59,103-104 

Vendor  definitions  ^  18 

Vendors  interviewed  101 


r 


-  127  - 

©1982  by  INPUT.  Reproduction  Prohibited. 


INPUT 


